Hi Bob. I know you said you want to write a book about Omeka and I invited you to use me as a guinea pig. Is it ok to post these emails publicly or is that giving away your manuscript? If you'd prefer, we can password protect them or make them private - or not post them at all. I do think they will be helpful to the rest of the team and to future team members. Let me know your preference and please add a copyright notice to this page. I suggest one of the Creative Commons licenses.
"Omeka - How To" email 20130928:
There are some people who use Omeka as if it were image centric, but that is not the right way to see it or use it. It is "item" centric. An item is one artifact that is cataloged within Omeka. LL20130928: We have a semantic confusion here. I have physical papers with printing or hand writing on them, cassettes with magnetic code on them, paper tape with holes that encode, paper and hardback book as well as lots of physical devices and toys in my office/storage in Milpitas, CA. I call these things "artifacts". When I scan a manual or a magazine I create a computer file that contains a digital image. Our challenge is to keep the digital image, the physical object and the database record that contains all the metadata connected. Eventually, after scanning and entering all the metadata relevant to an "artifact/physical object" that object will be transferred to another institution interested in preserving it. HCLE will only retain the images and the metadata. However, part of the metadata should make it possible for an HCLE visitor to locate the physical object as well as see its picture and learn about where it came from, how it was used in the past and possibly use it in the present. So if I have a widget, say a robot toy, that I haven't photographed yet, how do I make it an "item" in hclecatalog/Omeka?
That item can have any number of attributes to use for defining it, based on the "type" of artifact it is, and what attributes have been registered within Omeka to use when cataloging an item of that type. LL20130928: When you say "Omeka" above I'm assuming you mean the hclecatalog extended version of the Omeka platform, not something we register with the Omeka developers at George Mason University, right?
Out of the box, Omeka has a few item types already defined, with an interesting set of attributes available to use for each one of the types. LL20130928: Are the "set of attributes" each a separate table? I'm still interested in the database structure underlying what we're doing.
Something that is an artifact containing writing is easiest to call type "text" in Omeka, as you did with the letter you cataloged.
If you edit that item in Omeka, you are presented with a form to fill in having one data entry field for each possible attribute value that Omeka knows to use for cataloging a text type item.
That set of attributes includes all the Dublin Core attributes, which can be used to describe all items in Omeka. It also include a group of attributes that are unique to the "text" Item Type, labeled "Item Type Metadata" down near the bottom of the data entry form. LL20130928: I think it is going to take some serious study to figure out how to map my metadata onto what's already in Omeka. I'd like to talk to some of the other museum folks who are cataloging mixed media collections to see what decisions they have made and ask why they decided as they did. Do you know any of these folks?
The Dublin Core defines a "Description" attribute that can be a very long entry, with lots of explanation about the artifact.
The Text item type defines a "Text" attribute that could hold a transcription of the artifact, say the body of the letter that you cataloged, in plain text format, or even in html. LL20130928: This is a great example and one I've been wondering about. When you say "transcription" are you thinking of an OCR version of the image or something created by a human typist? Internet Archive and some of the other searchable sites are frustrating because the character recognition can be pretty bad.
Beyond the attributes that Omeka knows to ask for in the data entry form for cataloging an item, Omeka also allows the cataloger to enter "tag values" for the item. This is just another attribute that gives an easy way to view all items with a given tag value. Omeka provides a special navigation page to show all tags in the system with a link to find all cataloged items having a given tag value. The original idea of tags was for visitors to tag items, using words that have sense within the domain of interest. This approach did not live up to its promise. The reality is that cataloging an artifact and assigning a good tag is actually a skill task, not something that a casual visitor can do. In practice, tags are just one more attribute that is entered by the "professional" cataloger who enters the item into Omeka's system. LL20130928: When is it appropriate to create an additional attribute compared to when to use a tag? Has anyone published a commentary on this question?
Each cataloged artifact is put into Omeka by entering attribute values that describe it, and by entering tags to describe it. Do that for each artifact, and the catalog is built. LL20130928: This will work for new items that we are just scanning. It will be a slow way to get already cataloged collections entered.
One other part of Omeka is that each artifact that is cataloged with attribute values can also have one or many digital files associated with it. A digital file can be as simple as a jpg photo, or it can be video file such as quicktime movie or flash movie, or it can be a pdf or doc file, or it can be music file such as an mp3 file. The typical case is that the file is a simple jpg file but that is typical only because most Omeka user so far show an image of the artifact as their way of publishing a digital archive of the artifact collection. That is changing as many people are beginning to use Omeka for cataloging music or other recording artifacts such as life history stories, and videos of various sorts. LL20130928: This leads me back to wanting to understand the Omeka structure. With Access it was not a good idea to put the digital image file into the Access dbms because of its limited storage capacity and because that would have slowed the searching way down. Instead we created a separate folder and gave each item (record in the Access dbms) an attribute that was the url of the digital image. Now I need a procedure for getting those images associated with the Omeka items. When I export the Access catalog to a CVS formatted table the images are not there - and the old urls are not accurate in the Omeka system. Help!
Omeka provides a way to organize groups of artifacts into "collections". This is just a way to organize items. There is nothing in the real world that always maps to a "collection". In particular, a real world collection is not likely to map to an Omeka "collection". In the real world, all the artifacts might be called 'The HCLE Collection' as the name for the full group. But within Omeka, you might define a few Omeka "collections" that group artifacts into a logical cohesive group. Each cohesive group will belong to an Omeka "collection" even though they all belong the "HCLE Collection" in the real world. The curator of the archive is the person who defines the Omeka "collection" model, so that the items are grouped in a way to support the story that is told with the digital archive. LL20130928: I understand this although I'm not sure how to use it yet. Is there any limit to the number of "Collections" in Omeka? Can one item be used in many Collections? I was thinking of using this designation for items that might be related in an "Exhibit", say on upper elementary math software. We already use several attributes that indicate school subject matter and age group. Is membership in a Collection simply another attribute of an item or is there more to it than that in Omeka. The page displays let you choose "Collection" so I'm inferring that this designation is a first level sort to keep the visitor from random exposure to the everything in the catalog. - Oh, you answered my question below.
One type grouping might be by item "type" so that all letters are in one "collection". Another type grouping might be by "time", with Omeka collections defined for each time period that the curator has decided is important, say into decades, or say into rough regions of time ("early", "middle", "late"). Another way to group artifacts might be from who donated them, as in "James Smith Donation" for one collection and "Mary Brown's Estate" for another collection. Omeka does not impose any meaning on collections. A collection just gives a way for a visitor to view a group of items. Put items into an Omeka collection and they can be easily viewed by user navigating to the collection and viewing all items in that collection. No development work is needed to build that navigation feature. It's part of what Omeka brings to the party.
For artifacts related to computer technology related to learning, what are the possible ways to group the artifacts into "collections" to use in Omeka? Look at the actual artifacts already in hand and see if the give up any ideas on how to organize them into cohesive groups that support telling a story. I have not see the access database holding the set of already cataloged items so I am speaking completely from an imaginary perspective here as I suggest some possibilities.
As curator, I might want to have the artifacts seen from the perspective of how a person experiences the learning that came from the computer technology, with the distinction I want to talk about is the tension between formal systems of learning and informal systems. Was the technology a tool added to a formal curriculum and presented by a planned program that helped the learning occur? Or was the learning done outside a curriculum, enabled by the technology spreading through the culture outside of a formal curriculum, where the student learned by getting involved with it as a living event, maybe through family or friends? Was it somewhere in between, where a non-school institution set up a program outside a classroom setting to engage learners who came to visit. I don't know the names for these cases, but if I were an expert in the realm, I might already know them. With a little research, I could probably find the right terms for these cases. The terms for these cases would then be the names of the Omeka collections, and artifacts would be assigned to them by the curator as they are added to the archive. The curator would assign each artifact to a given collection to support the point of view that is being presented. LL20130928: These issues of curation are what I am really interested in. I'm so glad we are beginning to move beyond the technical aspects of the data base. I'm still cautious. I don't want to get tied to an inflexible data base that will have to be abandoned in two or three years and is so convoluted that migration will be an unmanageable nightmare. (I know, it's always a nightmare.)
Keep in mind that tag values can be used in a similar way to group artifacts into this type grouping. Omeka makes it easy to browse through groups of artifacts either with collections or with tags. Using a collection to group artifacts gives a better view of the grouping than just tagging. LL20130928: And there must be a way to construct custom queries as well. I'm looking forward to exploring that.
Note: in Omeka an attribute is called an "element", using the notation that comes out of the Dublin Core metadata initiative. That is what the Dublin Core folks call an attribute or metadata field. LL20130928: ...or a column in a table format? I was using the word, attribute, but I'm flexible. In my understanding there's no problem in changing vocabulary until someone starts putting special restrictions on a term we had been using interchangeably. That's why I'm asking so many questions. I'm probing for those "gottcha's".
The set of Elements that are defined for each item type within Omeka is a bare minimum, as it comes from the factory. If you want to increase the set of elements, that is done by editing an item type definition and adding a new element to it's definition. LL20130928: Good. Thank you. This is what I need to do the mapping from Access to Omeka, right? I'll explore a little.
If you want to edit the Item Type "Text" to increase the number of elements that are tracked for an artifact of type "Text", then you would go to the data entry page for editing the Text type definition:
At the bottom is an "Add Element" button. Click that to register a new element for Omeka to use when doing data entry to catalog an item of type "Text". Imagine adding an element named "Page Count". After adding that element, Omeka will start using that in the data entry form when a new "text" type item is added. No programming work is needed to have this happen. All new 'text' types will now include the Page Count attribute on the data entry form. When a value is entered into the data entry form, it will be saved and tracked for that item and will be displayed on the page that shows the details about the item. No programming work is needed to have this happen.
Mapping the columns you have in the Access database for each artifact is a simple operation. Just say which Omeka Item Types will be used, and which artifacts are which item type. Then make sure that the Omeka elements for a given item type match the columns that have been entered for the artifact type. If they don't match up, then add the needed "elements" to the Omeka item type definition.
If an artifact is not one of the pre-set Omeka item types, then add a new item type to Omeka which will be used for cataloging that artifact.
A completely new item type can be added to Omeka. All the elements that define the new item type are registered within Omeka. Then, any artifact can be cataloged as that new item type. During the cataloging step, the data entry form will have a field for each of the elements defined to be used to describe that item type.
It is a bit tedious to enter all cataloging information about each artifact using the Omeka form-based data entry system. Using cut and paste makes it a bit easier. For a small number of artifacts it is not too bad a task. It might take a few hours to catalog a hundred artifacts if the access database has all the values already filled in.
That will build up a very nice inventory into the digital archive, with Omeka providing a full blown navigation system for browsing through the archive and for searching it. No extra work is needed beyond entering the item description. The end result is a working digital archive ready for visitors to enjoy. LL20130928: So far we are in the few hundred range. Are you suggesting that the import feature is too flaky to bother with unless we are in the thousands?
If the inventory of artifacts is in the thousands, then doing the data entry by hand is not a good way. Then, it is time to use the CSV Import feature to catalog a batch of artifacts by providing all the element values to define each artifact using a comma separated value file. There are technical details that cause stumbles when doing this, but it can be done relatively easily. LL20130928: Wow, I'm really jazzed. For any of you random readers who got this far, we're going to need lots of data entry people very shortly. This is a good "public service gig" for bored high schoolers. We'll be working in Guerneville, CA, in Milpitas, CA and online. Get on board if you're bored, or enthusiastic about the project.
Back to hcle catalog discussion
Hi Bob. I know you said you want to write a book about Omeka and I invited you to use me as a guinea pig. Is it ok to post these emails publicly or is that giving away your manuscript? If you'd prefer, we can password protect them or make them private - or not post them at all. I do think they will be helpful to the rest of the team and to future team members. Let me know your preference and please add a copyright notice to this page. I suggest one of the Creative Commons licenses.
"Omeka - How To" email 20130928:
There are some people who use Omeka as if it were image centric, but that is not the right way to see it or use it. It is "item" centric. An item is one artifact that is cataloged within Omeka.
LL20130928: We have a semantic confusion here. I have physical papers with printing or hand writing on them, cassettes with magnetic code on them, paper tape with holes that encode, paper and hardback book as well as lots of physical devices and toys in my office/storage in Milpitas, CA. I call these things "artifacts". When I scan a manual or a magazine I create a computer file that contains a digital image. Our challenge is to keep the digital image, the physical object and the database record that contains all the metadata connected. Eventually, after scanning and entering all the metadata relevant to an "artifact/physical object" that object will be transferred to another institution interested in preserving it. HCLE will only retain the images and the metadata. However, part of the metadata should make it possible for an HCLE visitor to locate the physical object as well as see its picture and learn about where it came from, how it was used in the past and possibly use it in the present. So if I have a widget, say a robot toy, that I haven't photographed yet, how do I make it an "item" in hclecatalog/Omeka?
That item can have any number of attributes to use for defining it, based on the "type" of artifact it is, and what attributes have been registered within Omeka to use when cataloging an item of that type.
LL20130928: When you say "Omeka" above I'm assuming you mean the hclecatalog extended version of the Omeka platform, not something we register with the Omeka developers at George Mason University, right?
Out of the box, Omeka has a few item types already defined, with an interesting set of attributes available to use for each one of the types.
LL20130928: Are the "set of attributes" each a separate table? I'm still interested in the database structure underlying what we're doing.
Something that is an artifact containing writing is easiest to call type "text" in Omeka, as you did with the letter you cataloged.
If you edit that item in Omeka, you are presented with a form to fill in having one data entry field for each possible attribute value that Omeka knows to use for cataloging a text type item.
http://loopcntr.net/hclecatalog/admin/items/edit/1
That set of attributes includes all the Dublin Core attributes, which can be used to describe all items in Omeka. It also include a group of attributes that are unique to the "text" Item Type, labeled "Item Type Metadata" down near the bottom of the data entry form.
LL20130928: I think it is going to take some serious study to figure out how to map my metadata onto what's already in Omeka. I'd like to talk to some of the other museum folks who are cataloging mixed media collections to see what decisions they have made and ask why they decided as they did. Do you know any of these folks?
The Dublin Core defines a "Description" attribute that can be a very long entry, with lots of explanation about the artifact.
The Text item type defines a "Text" attribute that could hold a transcription of the artifact, say the body of the letter that you cataloged, in plain text format, or even in html.
LL20130928: This is a great example and one I've been wondering about. When you say "transcription" are you thinking of an OCR version of the image or something created by a human typist? Internet Archive and some of the other searchable sites are frustrating because the character recognition can be pretty bad.
Beyond the attributes that Omeka knows to ask for in the data entry form for cataloging an item, Omeka also allows the cataloger to enter "tag values" for the item. This is just another attribute that gives an easy way to view all items with a given tag value. Omeka provides a special navigation page to show all tags in the system with a link to find all cataloged items having a given tag value. The original idea of tags was for visitors to tag items, using words that have sense within the domain of interest. This approach did not live up to its promise. The reality is that cataloging an artifact and assigning a good tag is actually a skill task, not something that a casual visitor can do. In practice, tags are just one more attribute that is entered by the "professional" cataloger who enters the item into Omeka's system.
LL20130928: When is it appropriate to create an additional attribute compared to when to use a tag? Has anyone published a commentary on this question?
Each cataloged artifact is put into Omeka by entering attribute values that describe it, and by entering tags to describe it. Do that for each artifact, and the catalog is built.
LL20130928: This will work for new items that we are just scanning. It will be a slow way to get already cataloged collections entered.
One other part of Omeka is that each artifact that is cataloged with attribute values can also have one or many digital files associated with it. A digital file can be as simple as a jpg photo, or it can be video file such as quicktime movie or flash movie, or it can be a pdf or doc file, or it can be music file such as an mp3 file. The typical case is that the file is a simple jpg file but that is typical only because most Omeka user so far show an image of the artifact as their way of publishing a digital archive of the artifact collection. That is changing as many people are beginning to use Omeka for cataloging music or other recording artifacts such as life history stories, and videos of various sorts.
LL20130928: This leads me back to wanting to understand the Omeka structure. With Access it was not a good idea to put the digital image file into the Access dbms because of its limited storage capacity and because that would have slowed the searching way down. Instead we created a separate folder and gave each item (record in the Access dbms) an attribute that was the url of the digital image. Now I need a procedure for getting those images associated with the Omeka items. When I export the Access catalog to a CVS formatted table the images are not there - and the old urls are not accurate in the Omeka system. Help!
Omeka provides a way to organize groups of artifacts into "collections". This is just a way to organize items. There is nothing in the real world that always maps to a "collection". In particular, a real world collection is not likely to map to an Omeka "collection". In the real world, all the artifacts might be called 'The HCLE Collection' as the name for the full group. But within Omeka, you might define a few Omeka "collections" that group artifacts into a logical cohesive group. Each cohesive group will belong to an Omeka "collection" even though they all belong the "HCLE Collection" in the real world. The curator of the archive is the person who defines the Omeka "collection" model, so that the items are grouped in a way to support the story that is told with the digital archive.
LL20130928: I understand this although I'm not sure how to use it yet. Is there any limit to the number of "Collections" in Omeka? Can one item be used in many Collections? I was thinking of using this designation for items that might be related in an "Exhibit", say on upper elementary math software. We already use several attributes that indicate school subject matter and age group. Is membership in a Collection simply another attribute of an item or is there more to it than that in Omeka. The page displays let you choose "Collection" so I'm inferring that this designation is a first level sort to keep the visitor from random exposure to the everything in the catalog. - Oh, you answered my question below.
One type grouping might be by item "type" so that all letters are in one "collection". Another type grouping might be by "time", with Omeka collections defined for each time period that the curator has decided is important, say into decades, or say into rough regions of time ("early", "middle", "late"). Another way to group artifacts might be from who donated them, as in "James Smith Donation" for one collection and "Mary Brown's Estate" for another collection. Omeka does not impose any meaning on collections. A collection just gives a way for a visitor to view a group of items. Put items into an Omeka collection and they can be easily viewed by user navigating to the collection and viewing all items in that collection. No development work is needed to build that navigation feature. It's part of what Omeka brings to the party.
For artifacts related to computer technology related to learning, what are the possible ways to group the artifacts into "collections" to use in Omeka? Look at the actual artifacts already in hand and see if the give up any ideas on how to organize them into cohesive groups that support telling a story. I have not see the access database holding the set of already cataloged items so I am speaking completely from an imaginary perspective here as I suggest some possibilities.
As curator, I might want to have the artifacts seen from the perspective of how a person experiences the learning that came from the computer technology, with the distinction I want to talk about is the tension between formal systems of learning and informal systems. Was the technology a tool added to a formal curriculum and presented by a planned program that helped the learning occur? Or was the learning done outside a curriculum, enabled by the technology spreading through the culture outside of a formal curriculum, where the student learned by getting involved with it as a living event, maybe through family or friends? Was it somewhere in between, where a non-school institution set up a program outside a classroom setting to engage learners who came to visit. I don't know the names for these cases, but if I were an expert in the realm, I might already know them. With a little research, I could probably find the right terms for these cases. The terms for these cases would then be the names of the Omeka collections, and artifacts would be assigned to them by the curator as they are added to the archive. The curator would assign each artifact to a given collection to support the point of view that is being presented.
LL20130928: These issues of curation are what I am really interested in. I'm so glad we are beginning to move beyond the technical aspects of the data base. I'm still cautious. I don't want to get tied to an inflexible data base that will have to be abandoned in two or three years and is so convoluted that migration will be an unmanageable nightmare. (I know, it's always a nightmare.)
Keep in mind that tag values can be used in a similar way to group artifacts into this type grouping. Omeka makes it easy to browse through groups of artifacts either with collections or with tags. Using a collection to group artifacts gives a better view of the grouping than just tagging.
LL20130928: And there must be a way to construct custom queries as well. I'm looking forward to exploring that.
Note: in Omeka an attribute is called an "element", using the notation that comes out of the Dublin Core metadata initiative. That is what the Dublin Core folks call an attribute or metadata field.
LL20130928: ...or a column in a table format? I was using the word, attribute, but I'm flexible. In my understanding there's no problem in changing vocabulary until someone starts putting special restrictions on a term we had been using interchangeably. That's why I'm asking so many questions. I'm probing for those "gottcha's".
The set of Elements that are defined for each item type within Omeka is a bare minimum, as it comes from the factory. If you want to increase the set of elements, that is done by editing an item type definition and adding a new element to it's definition.
LL20130928: Good. Thank you. This is what I need to do the mapping from Access to Omeka, right? I'll explore a little.
If you want to edit the Item Type "Text" to increase the number of elements that are tracked for an artifact of type "Text", then you would go to the data entry page for editing the Text type definition:
http://loopcntr.net/hclecatalog/admin/item-types/edit/1
At the bottom is an "Add Element" button. Click that to register a new element for Omeka to use when doing data entry to catalog an item of type "Text". Imagine adding an element named "Page Count". After adding that element, Omeka will start using that in the data entry form when a new "text" type item is added. No programming work is needed to have this happen. All new 'text' types will now include the Page Count attribute on the data entry form. When a value is entered into the data entry form, it will be saved and tracked for that item and will be displayed on the page that shows the details about the item. No programming work is needed to have this happen.
Mapping the columns you have in the Access database for each artifact is a simple operation. Just say which Omeka Item Types will be used, and which artifacts are which item type. Then make sure that the Omeka elements for a given item type match the columns that have been entered for the artifact type. If they don't match up, then add the needed "elements" to the Omeka item type definition.
If an artifact is not one of the pre-set Omeka item types, then add a new item type to Omeka which will be used for cataloging that artifact.
A completely new item type can be added to Omeka. All the elements that define the new item type are registered within Omeka. Then, any artifact can be cataloged as that new item type. During the cataloging step, the data entry form will have a field for each of the elements defined to be used to describe that item type.
It is a bit tedious to enter all cataloging information about each artifact using the Omeka form-based data entry system. Using cut and paste makes it a bit easier. For a small number of artifacts it is not too bad a task. It might take a few hours to catalog a hundred artifacts if the access database has all the values already filled in.
That will build up a very nice inventory into the digital archive, with Omeka providing a full blown navigation system for browsing through the archive and for searching it. No extra work is needed beyond entering the item description. The end result is a working digital archive ready for visitors to enjoy.
LL20130928: So far we are in the few hundred range. Are you suggesting that the import feature is too flaky to bother with unless we are in the thousands?
If the inventory of artifacts is in the thousands, then doing the data entry by hand is not a good way. Then, it is time to use the CSV Import feature to catalog a batch of artifacts by providing all the element values to define each artifact using a comma separated value file. There are technical details that cause stumbles when doing this, but it can be done relatively easily.
LL20130928: Wow, I'm really jazzed. For any of you random readers who got this far, we're going to need lots of data entry people very shortly. This is a good "public service gig" for bored high schoolers. We'll be working in Guerneville, CA, in Milpitas, CA and online. Get on board if you're bored, or enthusiastic about the project.
Back to hcle catalog discussion